home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Collections: Topik
/
Topik - Disk 18 - Serious (19xx)(Topik Public Domain)(PD)[WB].zip
/
Topik - Disk 18 - Serious (19xx)(Topik Public Domain)(PD)[WB].adf
/
Qed
/
Qed_Notes.doc
< prev
next >
Wrap
Text File
|
1989-10-01
|
7KB
|
170 lines
QED Copyright 1989 by Darren M. Greenwald.
QED is a SHAREWARE; freely distributable Amiga text editor.
Last revised 5/22/89
General notes, comments, questions, and answers from the author of QED.
-----------------------------------------------------------------------
Over the past few weeks I have received several questions which
repeatedly keep coming up. Rather then answer the same questions over, and
over again, I have decided to use this file for this purpose.
-----
QUESTION - Why can't I use the LEFT AMIGA key in place of the RIGHT AMIGA
key to select menu items?
ANSWER - The LEFT, and RIGHT AMIGA keys belong to the operating system.
Intercepting these keys, or otherwise changing their functions is NOT a
recommended Amiga programming practice. In fact we are likely to see much
more use made of the LEFT AMIGA key by the operating system under version
1.4 of the operating system. Intercepting the LEFT AMIGA key is sure to
result in contention issues under 1.4.
Starting with beta version 0.14 of QED, the ALT keys are automatically
mapped to imitate the RIGHT AMIGA key alternatives listed in the pull-down
menus. Prior to this version, the CTRL key was mapped to imitate the RIGHT
AMIGA menu keys. This is both a valid programming practice, and allows you
to use either hand.
-----
QUESTION - How come LEFT AMIGA M/N don't work unless I have another screen
open?
ANSWER - LEFT AMIGA M/N is an operating system feature which moves the
Workbench screen to front & back. It never does anything unless you have
another screen open. QED runs on the Workbench screen; not its own screen.
-----
QUESTION - How come I can't respond to QED's requesters using LEFT AMIGA V/B?
ANSWER - LEFT AMIGA V/B is an operating system feature which allows you
to respond with a yes/no response to "AUTOREQUEST REQUESTERS" such as the
type used for system requesters.
QED does not use Auto Requesters because I find them unattractive,
and far too limited for the needs of the program. Auto Requesters also
do not allow for the use of string gadgets.
As stated above, the LEFT & RIGHT AMIGA keys belong to the operating
system. Application programs should not be intercepting, or otherwise
fiddling with system capabilities - this is the kind of programming practice
which often results in a program not working under later revisions of the
operating system.
Re-read page 3 of your 1.2 enhancer manual (at the top labeled - Page
4-30:). Note that this capability works for Autorequesters only; it was
never intended to work for application specific requesters.
Therefore, I will not attempt to imitate such a feature until such time as
it becomes an operating system feature. In the mean time, use of the 'o',
and 'c' keys is both easy, and rapidly becomes natural. Once you become
use to it, you'll wish every program made it so easy.
When a string gadget is active, it is not possible to obtain key press
messages without a great deal of system fiddling; the proper way to respond
to string requesters is with the RETURN key, and/or the other editing keys
which string requesters recognize.
-----
QUESTION - The file requester appears to be missing file/sub-dir names?
ANSWER - File requesters vary significantly in the Amiga software world.
Some sort file names, some dont. Some make you wait for the entire
directory to be read, some dont. Some separate the files from the
sub-directories, some dont. Etc...
There is really no "convention" as of yet. Few people can agree on how a
file requester should behave, and often users are rather confused by the
issues involved (the kinds of issues which programmers can spend hours
discussing).
No, QED's file requester is not missing file, or sub-directory names,
however, the list of names is not immediately redisplayed until the user
slides the proportional gadget. Why?
Many Amiga file requesters still make you wait for the entire directory to
be read before displaying anything, and some don't even allow you to enter
a file, or path name until the entire directory has been read. This is
often painfully slow for floppy users.
Some requesters, including QED's, solve this problem by allowing you to
select a file/sub-dir before the entire directory has been read. However,
it is my opinion that some programmers have not given this approach enough
consideration. The problem is that some requesters will continually, or
periodically redisplay the list of file/sub-dir names. Often this occurs
just as you are ready to click on a name, or just after you have finished
moving the proportional gadget to display the name you are looking for.
The net result is that you end up having to wait for the entire directory
to be read anyway as the list of names often changes faster then you can
read, or select. Worse, it takes additional time to continually redisplay
the list of names meaning it actually takes longer to read the entire
directory!
While it is often "cute" to watch the list of file/sub-dir names
continually change, it is also a pointless waste of time. At best the user
gets lucky, and can click on a name before the list is updated. Often it
is just not worth even trying, and the user gets to wait even longer for
the entire directory to be read.
-----
QUESTION - How about adding more features to the file requester?
ANSWER - At one time, I was working on the "ultimate" file requester for
QED. Without even thinking it somehow seemed important that QED have an
"ultimate" file requester.
As the features were being added, the size of the requester just kept
growing, and growing... all of this for what? In order to select a file
name!
At some point I realized I had lost sight of my original goal; namely to
write a relatively small, fast, and efficient text editor. I use a text
editor daily, and only a small fraction of that time is spent selecting
file names. So is it worth it to write a huge chunk of code for the sole
purpose of selecting a file name; an operation which takes just a few
moments?
The "ultimate" file requester should at least be available via a shared
library, and not replicated in every program.
Yet despite the apparent simplicity of QED's file requester, it has
features which many other file requesters don't. Memory is dynamically
allocated, and deallocate for the directory entries, and device list. So
large directories, or device lists are no problem. Many requesters can't
handle device names which are longer then 3 characters in length, however
device names can be as long as 31 characters in length; QED handles this
just fine.
Also the size of all of QED's requesters (including the file requester) are
adjusted to use your system font. This includes adjusting the size of the
windows, gadgets, borders, etc. Many requesters just look awful when using
a system font other then Topaz 8.
-----
QUESTION - QED does not recognize a font change using NEWFONT?
ANSWER - The only program which "properly" adjusts the system font is
Preferences.
QED has been successfully tested with Preferences, Setfont2, and FF by
MicroSmiths, Inc.
There is however a bug in Setfont2 which is apparent system wide in string
gadgets. This is evidenced by 2 different fonts being used in string
gadgets; 1 when the string gadget is active, and another when inactive.
This is a bug in Setfont2, and cannot be corrected by QED, however it
appears to be relatively harmless.